cms-admin: Add in-toolbar translate button to TipTap rich text block - #6235

getByText("Translation") and getByText("Hello world") each matched two
elements once the dialog was open (the dialog title reuses the same
message as the "Translation" column header, and the untranslated block
behind the dialog still showed "Hello world"), so the story failed.
Scope the lookups to the dialog and match the title by role instead.

Also add a story asserting that disableContentTranslation hides the
button even when the translation context is enabled.

getByRole("heading", { name: "Translation" }) matched two elements: the
dialog's own <h2> title and the "Translation" column header, which
MUI's Typography variant="subtitle2" renders as an <h6> (also a
heading). Disambiguate by the title's heading level.

Verified against a running Storybook instance via Playwright — the
story previously failed with a TestingLibraryElementError there.

Translating each text node separately lost sentence context across marks
(e.g. a bold or linked run got translated in isolation) and sent one
translate() request per node instead of one per field. Serialize a
field's content to HTML and translate it as a whole, matching the
Draft.js rich text block's approach. Link and child block data is
externalized to placeholder ids first, since it is an opaque object and
HTML attribute serialization only round-trips strings.

…oolbar

The in-toolbar translate button only translated the field's own text,
unlike the page-wide translateContent method, which also translates
link data and embedded child blocks via their own translateContent
hooks. Apply the same nested translation steps here.

A failed translate() call also had no error handling, leaving an
unhandled promise rejection with no feedback to the user. Catch it and
show the same error dialog the page-wide translate action already uses.

…nslation

mapLinkMarksData only externalized a link mark's data when it was
truthy, so a falsy value (false, 0, "", null, undefined) would be
serialized as a literal HTML attribute string and come back corrupted
after translation. setCmsLink's data is typed as any, so nothing rules
this out even though the link dialog always passes a populated object
today. Externalize link marks unconditionally instead, matching how
cmsBlock/cmsInlineBlock data is already handled.

…der id

translationContext.translate is typed as an unconstrained
(text: string) => Promise<string>, so nothing guarantees an
implementation leaves HTML markup and attribute values alone — the
existing uppercaseTranslate story double already demonstrates that a
caller can transform the whole string. Verify the placeholder ids
externalized for link/child-block data survive translation verbatim
before trusting the result; throw otherwise so the existing error
dialog surfaces the problem instead of silently restoring corrupted
data. Add TranslationRejectsCorruptingTranslate to prove this.

Also reorder the translation stories: basic toolbar behavior, then the
disabled/heading-level variants, then the "preserves" data-integrity
family, then the rejection case last.

…ant stories

Add unit tests covering the scenarios from the translation stories (bold mark
context, child block data, falsy link data, placeholders, and rejecting a
corrupting translate function), exercised through createTipTapRichTextBlock's
public translateContent method so they stay valid across future refactors.

TranslationPreservesFalsyLinkData and TranslationRejectsCorruptingTranslate
are dropped as stories: both assert pure data-preservation/rejection behavior
now covered exactly by the new unit tests, and TranslationRejectsCorruptingTranslate
in particular has no visible UI signal to justify a story (its own play
function notes there's no error UI to observe). The remaining 7 translation
stories still exercise the full button-click/editor/dialog integration.

Per review feedback: TranslationDisabled tested a trivial rendering check not
worth a story, and TranslationPreservesFormatting/ChildBlockData/Placeholders
duplicated exactly what the new unit tests already assert. Keep
TranslationRespectsHeadingLevels since it exercises the heading dropdown in
the review dialog, which nothing else covers.

…entAsync

The toolbar's handleTranslateClick and the block's translateContent both
called translateTipTapContentAsync followed by the identical two extra steps
for a link block's and child blocks' own translateContent. Move those steps
into translateTipTapContentAsync itself, taking linkBlock/childBlocksByKey as
options, so a field's full translation (text, links, child blocks) is one
call instead of a duplicated three-step sequence.

There's no sync counterpart, so the suffix only added noise; the same
naming slip motivated the earlier translateTextNodesAsync -> translate rename.

# Conflicts:
#	packages/admin/cms-admin/src/blocks/tipTap/TipTapToolbar.tsx
#	packages/admin/cms-admin/src/blocks/tipTap/createTipTapRichTextBlock.tsx

# Conflicts:
#	packages/admin/cms-admin/src/blocks/tipTap/TipTapToolbar.tsx
#	packages/admin/cms-admin/src/blocks/tipTap/createTipTapRichTextBlock.tsx

#6311 replaced the block's supports array with one option per feature,
each enabled by default and disabled by passing false (matching
undoRedoButtons, bold, heading, ...). Align the translate button's option
with that convention instead of keeping the lone negative, disabled-by-default
outlier, folding it into TipTapResolvedOptions alongside undoRedoButtons.